According to the Open Systems Interconnect (OSI) network model, functions involved in transferring data among devices in a network are distributed among different logical layers. The lowest layer represents physical network device hardware. Above that is a data link layer that places bits onto physical links and retrieves data from the links in data packets. Above that is the network layer, which provides the logical layout of the network used for efficient routing of data packets between devices on the network.
The Internet Protocol (IP) is a common network layer protocol. In IP, each packet comprises a header section and a payload. The header comprises, among other data, a destination network address and a source network address. The payload contains data for use by the next layers up.
Above the network layer is a transport layer, which segments data to be sent between two computers into a series of network layer data packets, and which reassembles the segments at the destination device. Generally, the transport layer is responsible for ensuring that the data is delivered error-free and in the proper sequence. The transport layer is also responsible for flow control, which manages transmissions so that the transmitting device does not send more data than the receiving device can process. A common transport layer protocol used on the Internet is the Transmission Control Protocol (TCP). Under TCP, each data packet that is processed comprises a TCP header and a TCP payload holding one or more data segments used by layers above the transport layer.
Above the transport layer is the session layer, which establishes, manages and terminates a communication session between two communicating processes on different network devices. Above the session layer is the presentation layer, which reformats data as necessary for compression or conversion before the data are used by the next layer up. Above the presentation layer is the application layer, where a program executes that generates or uses the transmitted data. For example, a client process (a “client”) is an application layer process that requests data from a server process (a “server”). The server is an application layer process on a different network device that provides a service, including data, in response to the request from the client.
The current implementation of TCP, as defined in Request for Comments (RFC) 793 and RFC 2001 of The Internet Society, places the burden of flow control in response to network problems on the transmitting side. This includes the burden of detecting network congestion and deciding when to retransmit. In general, servers do most of the transmitting, so the TCP process on the server device does most of the flow control determinations. Determining flow control involves storing and maintaining state data describing the data packets already sent, tracking an amount of time taken to receive an acknowledgement from the client that particular data packets have been received, and scheduling checks to see if no acknowledgement has been received within a time-to-live value that is specified for each packet.
A disadvantage of the current implementation of TCP becomes apparent when a single server device attempts to transmit data to thousands of clients. In such a case, the computational load on the server device to determine flow control for TCP becomes a limiting factor in server performance. For example, the amount of power consumed by the particular equipment suite used by the server increases substantially with the number of clients; and ultimately the number of clients that the particular equipment suite can serve may be limited. As more clients request services, expensive new equipment may have to be purchased and installed to meet the client demands.
One approach is to relieve the TCP process on the server side from maintaining state information about prior data packets send to a particular client. This “stateless TCP transmitter” approach saves memory consumed to store the state information for thousands of clients. A stateless TCP transmitter approach is described in co-pending U.S. application Ser. No. 09/901,523, filed Jul. 9, 2001, by J.-P. Champagne and J. Aviani.
However, this approach does not handle requests that prompt a server to provide multiple data packets in response. The stateless TCP transmitter is not able to process acknowledgements or determine when a particular data packet should be retransmitted, because the stateless TCP process does not record the time and contents of data packets already sent.
Another approach is to use a stateless transport process on the server, but to require the transport process on the client to continuously acknowledge receipt of each data packet. The server then stores only the last data packet, but no prior data packets, and resends the last data packet if an acknowledgement is not received within the retransmit time. A disadvantage of this approach is the excessive network traffic generated by acknowledging each data packet and the resulting slow transfer for connections with large round-trip time (RTT) characteristics. This approach is similar to that used in Trivial File Transfer Protocol (TFTP).
Based on the foregoing, there is a clear need for a transport layer protocol that does not place most of the burden for flow control on the server device and that handles responses involving multiple data packets.
In addition, there is a need for a transport layer protocol that works with a stateless server side transport layer transmitter.
The past approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.